Be sure to check the local docs/problems.html document, it
lists some common problems that are not caused by bugs in AWeb.
NOTE: This page does not list every single bug reported. If you have sent in a bug report, and it isn't on this page, that doesn't mean it hasn't been received.
Last updated December 19, 1996.
Latest additions:
"Unsupported process: SOF type 0xnn"
This error occurs on some web pages, probably due to the use of progressive JPEG images on those pages. This can be solved by installing the akJFIF datatype.
I cannot change the settings. Every time I try my Amiga crashes.
The ClassAct classes in the 1.2 and 1.3 archives contained a bug. Get the latest ClassAct archive from ftp://ftp.warped.com/pub/amiga/classact/ and everything should work fine.
During the install of AWeb, our installer won't over-write a ClassAct file if you have a higher version number file. We've found quite a few files that have a higher version number, but which are older than the ones we use. We don't know if these were beta versions, hacked versions, or whatever, but some of these don't work with AWeb.
We recommend you install the ones that came with AWeb, as we know those work.
Here's how to install the ClassAct files manually, forcing an overwrite.
copy all classes/#? sys:classes
copy classes/gadgets/layout.gadget.020 sys:classes/gadgets/layout.gadget
delete sys:classes/gadgets/layout.gadget.020
Also, if an older ClassAct gadget is in a different location in your
path (such as in Libs: or Sys:Classes) then it
may be used instead of the correct ones (in Sys:Classes/Gadgets).
If you still experience problems, check Libs: and
Sys:Classes for .gadget files.
If there are files in these directories that are also in the
Sys:Classes/Gadgets directory, delete them so the correct gadgets
in Sys:Classes/Gadgets are used.
Why does AWeb's picture colors look off, compared to viewing the same picture with a picture viewer?
With a picture viewer, you have the full array of colors to display them with - it's the only picture using them so it can use all the colors and change them at its whim. Because a web page typically has many pictures on it, all the pictures will have to share colors.
With multiple pictures, you have to have some way to "share" the colors between all the pictures. With a screen which has a fixed number of colors, AWeb has two methods to do this.
Load Spread Palette=Off
The first and probably easiest (but not necessarily the best) way is to allocate the colors first-come, first-serve. The first picture you use (say a 256 color picture) will come in, and take it's 256 colors. Say it's a picture of a plane in the sky, so there's around 100 shades of blue, 100 shades of greys and blacks, and maybe some white and red for detailing. Then the next picture you load is a 256 color picture of someone's face. All 256 colors are already taken by the plane, so it has to use the nearest colors. Sky pictures don't have lots of flesh tones, so most of the face will be the same red used for detailing, or maybe some of the greys will be the closest.
This is of course worst case, but hopefully you get the idea. The first picture will look great, after that they use the remaining colors, and when they're all gone, you have to use the colors from the previous pictures.
Load Spread Palette=Colors (the default setting)
This method will allocate a spread range of colors, and all pictures will use these colors. There will always be a wide range of colors so that any color in the picture will be close to what is available. This does mean that you don't have a wide variety of a specific color.
In the two examples above, a sky picture will not have access to all 100 shades of blue, as there may only be say 20 shades of blue in the spread palette, so you may see "bands" of blues because of the limited range. The "portrait" alone may also not look as good as on its own screen, again because there may be only 20 flesh tones. However, on the same screen together, they'll both still be acceptable, and for this matter, no matter how many pictures you display, and whatever order they are displayed, they'll be consistant.
Load spread palette item. This is in the
Settings/Program Settings menu item, under the Screen
file folder tab. AWeb has to be using it's own public screen.
If you have a graphics board with 16 and 24 bit graphics modes, you can get a much better display, because you are no longer limited to the number of colors. Essentially each pixel can have its own color, and thus you don't need to share colors. With AWeb, you can do this if you have a Cybergraphics supported graphics board and the V43 picture datatype.
Print function will show the status bar quickly then return without printing.
AWeb currently attempts to print graphically using the same screen depth you have selected. If you are using a 16 or 24-bit screen with the Cybergraphics software, then the Amiga printer drivers are unable to handle the 16 or 24 bit deep bitmap graphics, and will not print anything. If you wish to use the graphical print function, change your screen mode to an 8-bit (256 color) screen before running the print option.
In-line images are no longer displayed in AWeb
The V43 (24-bit) picture datatype commonly used by people with graphics boards is beta software. The previous version, 43.753, has built into it an expiry date after which point it will fail to display any images. As of November 16, this version has expired.
If your AWeb now fails to display in-line images, and Multiview also fails to display these images, and you use the V43 (24-bit) picture.datatype, this is likely the cause of your problem.
The new V43 datatype should be available from ftp.phase5.de, and should also be available from your nearest Aminet mirror site. The version number of this one is 43.755, and supposedly does not have an expiry date.
If you are unable to obtain the new datatype in a timely manner, you can temporarily set back your system date to some date before November 16 to get it to work again.
A more extreme measure is to return to the normal V40 picture datatype as supplied on your Workbench disks, and install the zgif datatype (version 39.18) for GIF pictures, and either the akJFIF datatype or JFIF datatype for JPeg pictures, which are available from our web site at http://www.amitrix.com/aweb.html, or from Aminet.
"SYS:Prefs/ClassAct: file is not executable"
There is a known problem with some versions
of ClassAct Prefs (2.107 in particular, maybe others).
This version of ClassAct Prefs does not run as a shell command,
thus the AWeb Settings/ClassAct Settings... menu
of AWeb will produce an error message:
"SYS:Prefs/ClassAct: file is not executable"
If you experience this problem, please copy the ClassAct preferences
program ClassAct/ClassAct from the temporary archive directory
to Sys:Prefs/.
Napsaterm setup under AmiTCP
First, put the path name in the telnet command line in settings, and one "%s" in the arguments line. To get it to run on the AWeb screen you must change the parameter in the db/napsaprefs file for the screen to AWeb instead of Workbench. This works, where passing the parameter from the command line does not!
That should allow it to work with other TCP stacks as well, but this hasn't been fully tested.
Finally, the version of Napsaterm found in the AmiTCP 4.0 demo is v3.9, which is newer than the one on Aminet, which is v3.8b.
JPEG display problems using JFIF datatype
See "Configuring the JFIF datatype" in Docs/install.html. Essentially, in the JFIF preferences editor, add an application named AWebIP, not AWeb.
The settings requester listview does not redraw the screen if the pointer is dragged out of the window while selected.
This is an Intuition bug in WB3.0 and is being referred to the ClassAct authors for a work-around. Re-sizing the AWeb window will usually force a redraw.
The AWeb TCP auto-start/stop function does not work.
Workbench paths are not passed to a script started from within the program. Add this statement to the top of both AmiTCP:bin/startnet and stopnet scripts:
Path sys:rexxc add
I can't install AWeb. The installer reports errors like: Unable to compile script.
Most likely some misbehaving application installation has copied an
obsolete version of the Commodore Installer utility to your hard drive.
Make sure the Installer version in the SYS:C directory is
"installer_2 2.17 (1993-02-13)"
or better. This version can be found on
the Amiga Workbench 3.x Install floppy disk.
Also, delete any copies of the Installer program from your
SYS:Utilities drawer.
On many pages, GIF images are trashed. And sometimes AWeb crashes when loading a GIF image.
The commonly used ZGif datatype version 39.16 had a bug. Be sure to use version 39.18 or better of the ZGif datatype, or another GIF datatype.
I have got a copy of AWeb, and I find it excellent, except for one reason: it requires wb3.x! Is there or could you make a copy that works on wb2.x.
AWeb uses datatypes for showing inlined images, and datatypes are an OS 3.x feature. An OS 2.x compatible version of AWeb is currently not planned. You should consider upgrading to OS 3.x, as more and more programs will come out that require at least OS 3.x.
With some forms, I get a "Server error", or no results. With AMosaic it works fine.
This is really an error in the server. To reduce network traffic, AWeb doesn't send empty fill-in fields, which is perfectly legal acording to the HTML standard. Some servers have problems with this, though. This problem is solved in AWeb version 1.1 and above.
I have a 68000 machine and AWeb crashes in the "looking up" phase on some pages, e.g. www.yahoo.com.
This was a bug in AWeb 1.0 and is fixed in version 1.1 and above.
AWeb takes ages to load!
You have probably installed AWeb with large fonts. AWeb then uses the CGTimes font. If you want AWeb to load faster, a simple solution is to reinstall it with small fonts. Another solution is use Intellifont to create a bitmap for every fontsize you are using in AWeb.
AWeb doesn't display all of the page. Other browsers display the page correctly.
Probably the page contains some erroneous HTML. One of the common errors
is the use of something like <!---------------------->
as a dividor line in the HTML source. This can lead to large parts
of the page commented out if the number of dashes is not exactly
right.
Apart from notifying the author of the page that his page contains
erroneous HTML, you can try to select
Control / HTML mode / Compatible from the menu.
AWeb becomes terribly slow if I run it on its own screen.
This has something to do with chip memory usage and DMA bandwidth. Apparently, the problem becomes worse when you have an accelerated machine. The solution is to use either a lower or a higher speed ("baudrate") to communicate with your modem. Start at the modem speed (so if you own a 14.4k modem, start at 14.4k communication speed). Then increase the speed until you find a dramatic slowdown. Then go one step back. Changing the communication speed with your modem might involve adapting the settings for your dialler, TCP stack and/or your SANA driver. Refer to the respective documentations.
Backgrounds in AWeb are terribly slow, much slower than competitive Amiga browsers.
This might be caused by an unsuited picture datatype. Use the 24-bit picture datatype only on CyberGraphics screens; on original Amiga screens this datatype becomes very slow. Use the original picture.datatype from your Workbench diskette.
The colour requester from the Screen 2: palette settings page messes things up on a CyberGraphics screen.
This is caused by the palette-orientated design of the Amiga OS. This works fine on Amiga chipset screens, but isn't really suited for graphics cards.
Closing the AWeb public screen while there is a visitor window open crashes if the screen is a CyberGraphics screen.
This is a bug in CyberGraphics V 2.15 and lower. The same thing happens on other CyberGraphics screens.
If the window is not active, a click in the scroller container (outside the knob) moves the scroller but doesn't scroll the window contents.
This is a bug in Intuition. The same thing happens sometimes with MultiView.
I use MagicMenu, and every now and then my system hangs if I open a menu.
This is a known problem in MagicMenu, caused by the fact that MagicMenu is not 100% compatible with the way Intuition handles menus.
I don't use MagicMenu, but my system hangs if I click on the wide part of the chooser gadget in the settings window.
Be sure to use the version of chooser.gadget included in
the AWeb 1.1 or above archive.
Also, some animated mouse pointer commodities are known to cause this
hang.
I received my keyfile UUencoded, but now AWeb says "keyfile size error". I used THOR to decode it.
THOR doesn't decode the file right. It adds an extra byte, which would make AWeb crash if it didn't check the size. Use another UUdecoder, or use a binary file editor to remove the last byte from the file (at your own risk, use a copy of the keyfile). The correct size for the keyfile is 376 bytes.
Questions, comments and suggestions regarding this FAQ should be sent to support@amitrix.com.